Data-driven navigation and navigation routing

ABSTRACT

The described technology is directed towards data-driven navigation, in which a next navigation location depends on variable data associated with an interactive user interface element (rather than a fixed link). The data may be in a hierarchy of data models. A menu contains interactive navigation elements, each bound to a data model. A selected interactive navigation element results in locating a data model associated with the selected element. The data model is used to determine the next navigation location. Also described is hierarchical navigation to one item of a level as well as lateral and peer navigation.

CROSS-REFERENCE TO RELATED APPLICATION

The present application claims priority to U.S. provisional patentapplication Ser. No. 62/046,094, filed Sep. 4, 2014, the entirety ofwhich is incorporated herein by reference.

BACKGROUND

A typical way to present interactive content to a user is by a set ofpages. In general, a user starts at a home page, which contains links toother pages, and each other page may or may not contain its own links. Auser thus navigates among the pages by actuating links (e.g., clickingon them or touching them) as placed by the developer. Home, back andforward buttons are also typically provided to assist the usernavigation.

While this works for structured page content, it has drawbacks for othertypes of content, such as if the structure needs to change. For example,consider that an existing page needs to be divided into two (or more)pages, or that some new type of content is added that benefits fromhaving its own page, rather than being placed on an existing page. Insuch situations, the developer has to recode each impacted page,including to update the links on possibly many pages to provide fornavigation to the new page (or pages).

SUMMARY

This Summary is provided to introduce a selection of representativeconcepts in a simplified form that are further described below in theDetailed Description. This Summary is not intended to identify keyfeatures or essential features of the claimed subject matter, nor is itintended to be used in any way that would limit the scope of the claimedsubject matter.

Briefly, the technology described herein is directed towards data-drivennavigation. One or more aspects are directed towards rendering arepresentation of a navigation location, including providing a set ofone or more interactive user interface elements that are each bound to adata model. A user interface element is selected that is bound to anassociated data model. The associated data model is accessed so as touse data in the associated data model to determine a next navigationlocation.

Other advantages may become apparent from the following detaileddescription when taken in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The technology described herein is illustrated by way of example and notlimited in the accompanying figures in which like reference numeralsindicate similar elements and in which:

FIG. 1 is a block diagram showing example components that may be usedfor data-driven navigation, according to one or more exampleimplementations.

FIG. 2 is a block diagram and data flow diagram including an examplerepresentation of a home page that is rendered based upon a retrieveddata model for that home page, according to one or more exampleimplementations.

FIG. 3 is representation of an example data model hierarchycorresponding to items on the home page, according to one or moreexample implementations.

FIG. 4 is a representation of a new location (e.g., a menu page)rendered based upon a data model bound to a home page data element,according to one or more example implementations.

FIG. 5 is representation of an example data model hierarchy whichdata-driven navigation is configured to traverse, according to one ormore example implementations.

FIG. 6 is an expanded representation of (part of) the example data modelhierarchy of FIG. 5, according to one or more example implementations.

FIG. 7 is representation of a modified example data model hierarchywhich data-driven navigation automatically is able to traverse,according to one or more example implementations.

FIG. 8 is representation of an example modified set of data modelscorresponding to the data model hierarchy of FIG. 7, according to one ormore example implementations.

FIG. 9 is a representation of a new location (e.g., a menu page)rendered based upon the modified data models corresponding to FIGS. 7and 8, according to one or more example implementations.

FIG. 10 is a representation of another new location (e.g., a menu page)rendered based upon a further modified data model, according to one ormore example implementations.

FIG. 11 is a flow diagram showing example steps that may be taken by anavigation system to provided data-driven navigation, according to oneor more example implementations.

FIGS. 12A and 12B are representations of hierarchical navigationincluding lateral navigation and a navigation stack, according to one ormore example implementations.

FIG. 13A is a representation of navigation among locations includinglocations designated as anchors, according to one or more exampleimplementations.

FIG. 13B is a representation of an example of automatically generatedsimulated navigation history, according to one or more exampleimplementations.

FIG. 14 is a block diagram representing an example computing environmentinto which aspects of the subject matter described herein may beincorporated.

DETAILED DESCRIPTION

Described herein is a technology that uses data to drive navigationamong locations (e.g., pages and other user interface mechanisms) ratherthan page code, where in general, a location is an association between anavigation system that navigates to the location and a renderer thatknows what to render based upon the type of location (e.g., a menu) anddata (e.g., interactive tiles) associated with that location. To thisend, locations are decoupled from the act of navigating. This is incontrast to a conventional link arrangement in which a location isassociated with each link.

By way of example of the technology described herein, a page location(or other interactive element such as a drop-down menu) may contain anumber of interactive user interface (UI) elements related to locationnavigation, e.g., one or more buttons, icons, tiles and/or the like.Each such element is bound via a suitable identifier to a particular setof associated data, referred to herein as a data model. When a givenelement is selected (e.g., clicked), the data related to that element isobtainable from the element's associated data model. Indeed, the homepage itself may be made dependent on an underlying data model, (althoughsome of the home page may contain fixed layout information and possiblysome relatively fixed additional data, such as a company's logo orreference thereto). If a change is desired, the underlying data modelbound to any location and/or its corresponding UI element may be changedat any time, which may be done without any modification to the home pagecode or any other page code. As one example result, if the data bound toa user interface element is changed, the navigation locationautomatically may change based upon the updated data.

When an element is selected, (e.g., clicked, touched or otherwiseactuated), the home page need not have any concept of what a nextlocation may be for that element, or any purpose underlying thatelement. Instead, the page only knows that the selected element is boundto a particular other data model by a suitable identifier, and that anavigation system is to be invoked with the identifier. When the otherdata model is accessed by the navigation system, the data model itselftells the navigation system a next action to take, which, for examplemay be to render and navigate to a new menu page based upon the otherdata model, or to render a content (e.g., movie) player page that playsa movie identified in the data model, or to render a search page, or topresent some text and/or image data corresponding to the data model, andso on.

As a result, a developer only needs to provide a home page that binds toa “home page” data model having one or more interactive elements thatare each in turn bound to another data model. If a change is needed, theunderlying home page data model changes, however the home page code neednot change. Further, no other pages need to have any links updated,because any such “links” are instead locations that are automaticallyprocessed from the changed data model.

As a more particular example, on a home page (bound to some data modelX), an interactive UI element may be associated with an identifier forsome other data model Y, e.g., via an object ID for Y. When the homepage is rendered, the home page renders the UI element that is bound tothe data model Y. Note that the data model X contains at least theinformation as to the type of UI element to render, such as a tile, andthe content (e.g., text) to render within that element; however it isfeasible that the data model X may contain other variable appearanceinformation for an element to be rendered, such as color, desired size,animation data, and so forth.

Once rendered, if the UI element associated with data model Y is laterselected, the navigation system is invoked to access the data model Yand perform a next action based upon action data (that is, navigationdata) in the data model Y. For example, the data model Y may containinformation indicating that the data model Y represents a “menu” pagecorresponding to a data model Y, whereby the navigation system knows torender a new menu page that is based upon other data in the data model Y(such as with new interactive elements containing text, relativelocations for the elements, and each respective object ID for any othercorresponding data model to which each new element is bound; text,images and so forth including references to external data also may be indata model Y). As needed, the navigation system may retrieve any otherdata identified in the data set Y. The navigation system then renders anew menu page based upon the data in data model Y, and navigates to thatnew menu page to allow for interaction with the newly rendered menupage's interactive elements.

As will be understood, if sometime later a change is desired to thatother menu page (for data model Y), such as to add a new interactiveelement or change an existing one, only the data of data model Y need bechanged, not any page code/logic. This leverages the fact that amenu-type page may be coded once to know how to lay out its interactiveelements and other UI components, and thus such page code only needfollow the information in the current data model, and need not beseparately replicated for each similar page, nor linked to from otherpages, nor contain any hardcoded links.

Similarly, a different type of location such as a movie player “page”need be coded only once to present and play a movie, given theidentifier of that movie from a data model. Thus, although theidentifier of the movie may change, the movie player location code neednot change for each movie.

It should be understood that any of the examples herein arenon-limiting. For example, only certain types of navigation locationsare exemplified herein, including a “menu” location, a content (e.g.,movie, TV show, video) “player” location and a “search” location,however these are only non-limiting examples and numerous other types oflocations are feasible. As such, the technology described herein is notlimited to any particular implementations, embodiments, aspects,concepts, structures, functionalities or examples described herein.Rather, any of the implementations, embodiments, aspects, concepts,structures, functionalities or examples described herein arenon-limiting, and the technology may be used in various ways thatprovide benefits and advantages in computing and navigation concepts ingeneral.

Turning to an example implementation, FIG. 1 shows a view host 102hosting a home page 104. The view host 102 may be any suitable componentin which user interface (UI) elements may be rendered, such as anobject, the entire display, a portion of a display, a program window, aprogram's drop-down menu, a container (e.g., object), and so forth. Thehome page 104, as will be understood, comprises a “menu” locationcomprising a page, which, for example, may be a container UI elementinto which interactive UI elements such as icons, buttons and/or tilesmay be rendered.

As is understood, in one or more implementations, at least some of theexemplified components in FIG. 1 may be objects, and thus may be hostedin other objects, interfaced with other objects, and so on. FIG. 1 isthus only an illustrative example, and the technology is not limited toany particular division of the components. Indeed, any of these examplecomponents may be combined, any component may be further divided intosub-components, and other components may be included in a given system.As is also understood, each figures including FIG. 1 is only an example.

As part of rendering the home page 104 (e.g., via renderer 106), anyavailable home page content 108 (optional, as indicated by the dashedbox) that may be present in the home page 104 may be used, along withthe data model corresponding to the home page, which is known from thedata model identifier (ID) 110. Note that via the home page content 108,the home page may be customized with something non-standard for atypical menu page, such as to let the user know that he or she is at thehome page. However, because the home page is a menu location, no suchoptional content 108 need be present, as such data may be entirelycontained in the home page data model.

The data model ID 110 is provided to a navigation system 112, whichretrieves the “home page” data model from a set of data models 114, anduses the data model's data to determine the location type (e.g., menu)of the home page data model from a set of available locations known tothe navigation system 112 and the renderer 106. Because in this examplethe home page is a menu location, the navigation system 112 provides anindication of the kind of location to render and thereby in this exampledirects the renderer 106 to render a menu-type page. The renderer 106does so with one or more interactive elements that are based upon datain the home page data model. Note that data models may be objects in anobject-oriented sense, and are often referred to as data model objectsherein, however it is understood that “data model” or “data modelobject” refers to any suitable data structure or part of a structurethat can be referenced to provide the desired data.

By way of example, FIG. 2 shows a rendered home page 222 for presentingmedia content, which may be hosted in any suitable view host 224 such asa browser, operating system window, dedicated application, UI containerand so forth. The home page 222 contains four interactive UI elements,labeled as “TV Shows” 225, “Top Movie” 226, “All Movies” 227 and “NewThis Month” 228.

To obtain the information via a home page data model, the view host 224(or other suitable code) communicates with a navigator 230 (an object orthe like) in a navigation system 232, as represented by arrow labeledone (1). The navigator 230 accesses the set of data model objects 234(arrow two (2)), and thereby obtains the data model object 236 bound tothe home page 222.

The data model object 236 is received (arrow three (3)) and processed bya navigation router 238 (e.g., an object) to determine what the datamodel object 236 represents, e.g., how navigation is to occur, which isbased upon the data in the home page data model object 236. In thisexample, the navigation router 238 determines from the data and knowntypes of locations that the type of location is a menu, and providesthis information to the navigator 230 (arrow (4)), and thereby in turnto a renderer 242 (arrow five (5)). The renderer 242 thus renders a menupage, using the information in the home page data model object 236 torender the UI elements 225-228. In this example, the information knownis that there are four “tile” data elements, labeled—“TV Shows” “TopMovie” “All Movies” and “New This Month”—respectively.

This is exemplified in FIG. 3, where the data in the home page datamodel object 236 indicates that it is a menu location, and lists, in theorder to be rendered, “TV Shows” “Top Movie” “All Movies” and “New ThisMonth” as interactive tile elements. While this simple format thus maybe used to accomplish the data driven navigation, it is understood thatthis is only an example, and that a more elaborate format may bepresent. For example, for each element, instead of or in addition tobasic text, image/icon data (the image data itself or a referencethereto), appearance information, (e.g., red text on a white backgroundin a specified font and size), animation data, video data and so forthmay be provided. With additional information, the elements need not berendered in the order provided, e.g., the data may specify to renderthem alphabetically or based upon some other ordering scheme. Similarly,note that instead of simply identifying the location as a “menu”location, additional information regarding the menu's appearance may beprovided, e.g., fixed menu text and/or images, background color and soon. As long as the renderer knows how to interpret such appearanceand/or other data for a menu location, the menu and its elements arerendered as specified in the data.

Further, an element layout pattern may be provided in a data model,e.g., horizontal, vertical, grid or the like. Note that thisalternatively may be accomplished by specifying different menu types,e.g., a horizontal menu, a vertical menu, a grid menu, instead of thesingle “menu” type identified in the example data model object 236 ofFIG. 3.

Still further, the renderer 242 may use a factory to provide a viewobject for rendering (as is generally known in object-orientedprograms). This may include styling data for the view, e.g., color, textfont and size, animation data, and so on.

As also represented in FIG. 3, each of these UI elements 225-228 isassociated with its own data model 325-328, respectively, e.g., eachcomprising a data model object having a suitable identifier. Note thatan identifier may be an actual object ID (that is at least unique in agiven namespace), however in the example of FIG. 3 such an object ID isnot shown for purpose of clarity; instead the data model's element(tile) text is shown (via the dashed arrows) as being coupled to arespective data model object.

When a UI element is selected, the home page 222 does not know anythingabout the selected UI element's purpose. Instead, a UI element isselected, the home page 222 in general only needs to identify theassociated data model object to the navigation system 232, whichdetermines from that identified data model object a navigation action totake. Indeed, as will be understood, the UI elements for “TV Shows” 225,“All Movies” 227 and “New This Month” 228 will result in (different)menu pages or the like being rendered, whereas the “Top Movie” 226, willinvoke a movie player location (page), which for example may beginplaying the top movie (identified in its respective data model)automatically, without any additional user interaction. As can be seen,the home page 222 need not be coded with any of this information, and ingeneral once rendered only needs the ability to communicate the datamodel object ID of which UI element was a UI element is selected to thenavigation system upon selected of an element.

The data model object for each UI element contains the action for thatUI element, e.g., navigate to a menu (or other page), activate a movieplayer to automatically (or if desired, interactively) play the “TopMovie” title, or do something else, like present text and images on astatic or mostly static page.

Thus, in the example of FIG. 4, consider that the “TV Shows” element 225gets selected; as can be seen from FIG. 3, this results in a new datamodel object 332 being retrieved, namely the one bound to the “TV Shows”UI element. As also understood from FIG. 3, the location type of thisdata model object is “Menu” and also specifies four interactive UIelements comprising tiles, namely:

-   -   Tile=“Featured TV Shows”    -   Tile=“Popular TV Shows”    -   Tile=“Recent TV Shows”    -   Tile=“Older TV Shows”

When the “TV Shows” menu page 444 is rendered as represented in thelower portion of FIG. 4, appropriate interactive elements 425-428 forthese tiles appear in the menu page 444. It is seen that otherinformation such as text, and a “star” image also is rendered in thisexample, although the data for these (whether actual data or via areference thereto) is not shown in the “TV Shows” data model 325 forpurposes of clarity and brevity.

Note that a back button 446 and a home button 448 also appear in thisexample menu page. As described below, whether each such button appears(or perhaps almost always appears but is sometimes inactive anddisplayed as grayed out or the like) depends on whether there is ameaningful place to navigate back to if selected. In this example theuser may go back to the home page, so such buttons 446 and 448 arelikely active and appear in an active state. Because the navigationsystem 232 generally handles the management of these buttons, the datamodel does not specify them (although it possibly may specify where andhow they appear if rendered, such as to go with a page theme).

Returning to FIGS. 2 and 3, consider that the user has instead selectedthe “Top Movie” tile. As seen in FIG. 3, the associated data modelobject 326 is not a menu location, but rather a movie player location.The navigation system 232 thus navigates to a movie player page, withthe movie identifier that is present in the data object used to accessthe correct movie.

In one or more implementations, a content (e.g., movie) player page maysimply start playing the content, with no additional user interactionneeded. In alternate implementations, a content player page may insteadallow some user interaction, such as a UI element to allow a user toread content details (e.g., for a movie, cast and crew, reviews and soon) along with a UI element in the form of a play button play thecontent. Such an interactive page need not be a menu, as interaction mayonly change what and how visible content is displayed on the page, asspecified in the data model object. However, a content player page datamodel object also may include a UI element that binds to another datamodel object, and in this way acts as a menu page. There is nolimitation on how pages and data models may be used, as long as thenavigation system knows how to handle such a location. Indeed, there maybe different types of content player pages in the same system(differentiated by data in the corresponding data model object) or thedata model object may include information such that as little as asingle location can handle multiple types of content player pages, e.g.,via data that specifies “play at once” or “play after ten seconds if nointeraction” or “play only on a “play” button, and so on, with anyadditional interaction options specified.

Among other advantages of data-driven navigation, consider that the datamodel hierarchy needs to be changed. FIG. 5 shows part of an exampledata model hierarchy 550, which generally mirrors the examples of FIGS.1-4. FIG. 6 shows a data model hierarchy 660 comprising the top portionof FIG. 5 somewhat expanded into more detail.

As one example, consider that in the data model hierarchy 660 of FIG. 6there are too many shows 662 listed under the “Older TV Shows” category,e.g., because users have provided feedback indicating that it takes toolong to scroll among the many shows to find a desired one. Thus, thedata model hierarchy 660 of FIG. 6 is changed to the data modelhierarchy 770 as in FIG. 7, to include new sub-menus 772 under the“Older TV Shows” selection, such that the shows 662 under the “Older TVShows” category needs are grouped into subcategories, generally dividedby decades—“2010s” “2000s” “1990s” and “1989 & Before”—.

As shown in FIGS. 8 and 9, nothing other than the data models need tochange, e.g., the data model object for “Older TV Shows” is changed to a“menu” location comprising UI tile elements (FIG. 9), instead of a“content player” location (possibly a different one for television showsversus movies) that includes a large list of the older shows (notseparately shown). In conjunction with the new element creation, fournew data model objects are created that each are content playerlocations, one for “2010s”, one for “2000s”, one for “1990s” and one for“1989 & Before,” with the list of older shows divided under each datamodel object by their dates. When the “Older TV Shows” element 428 isselected (FIG. 9), a menu page 920 with the desired new UI elements925-928 is rendered. In a conventional link-driven navigation system,such a change is not possible without also changing the page code andlinks, because a conventional page only knows to display a single listof shows and link to play a selected show, for example.

FIG. 10 shows this example taken further, where it is decided that “1989& Before” is also not specific enough. However, it is deemed by thedecision makers that a new submenu is not needed for this purpose, butrather a more granular division of the data. Thus, the data model objectfor “1989 & Before” is not changed to a menu location, but rather thedata model object “Older TV Shows” is updated with additional tiles toprovide an updated data model object 1060, and the data model object for“1989 & Before” is divided up and replaced with data model objects for:“1980s” “1970s” “1960s” and “1950s & Before” in this example, each witha corresponding tile UI element in the “Older TV Shows” data model. Notethat the container that presents the new UI elements when rendered is ascrollable container in this example.

FIGS. 9 and 10 also demonstrate a new type of interactive element,comprising a search button 950. In data driven navigation, astraightforward way to do this is to add a “Search ???” UI element as a(modified) menu item, such as with rendering instructions that tell therenderer not to render the search button in line with the otherselections so as to stand out to the user. If selected, the searchbutton may be linked to a search page location, which may be in the formof a menu, such as one configured based upon a search data model (e.g.,specifying a text input field) to receive alphanumeric characters and tosearch a namespace of the relevant place in the current navigationhierarchy; e.g., when search is selected, navigate to “search datamodel” with namespace=all titles under “Older TV Shows” or the like. Thesearch data model identifies that it is a search page; (there may bedifferent types of search data models and search pages, such as one forcategory searches that differs from alphanumeric searches), hence a datamodel for each, however if not, a single data model for all searches maybe used. In this way, it is straightforward to add data to a menu pagethat enables a search of any namespace corresponding to that menu page.Again, in this example there is no change to any page code or link onany page involved, only a change to the data model of a menu page toprovide access to search functionality from that page.

Significantly, data model objects may be reused across different menusproviding the benefits of reuse, (as well as other advantages related tonavigation, described below). For example, consider that a moviecategory of “Popular now” includes a movie tile for some movie “ZZZ”along with other movie tiles that are deemed popular. The same movietile “ZZZ” may also appear in a “Recent” menu, an alphabetic menu, acomedy genre menu and a romance genre menu. As another example, considerthat a button such as “Top Movie” may appear in a “Suggested” menu aswell as a “Home” page menu. Simply manipulating data in the appropriatedata model objects allows this to function seamlessly.

FIG. 11 summarizes some of the above concepts in a simplified flowdiagram containing example steps for handling data-driven navigation,starting at step 1102 where the home page data model is obtained andused to render the home page at step 1104. FIG. 11 is limited todata-driven navigation to menu pages, a content player page, and asearch page, although as is understood, any number of other locationtypes may be recognized by the navigation router and appropriatelyhandled. In this example, interaction options may be active or notactive (or not present) at times, including search, home, back, and soon.

Step 1106 represents waiting for user interaction with the currentlyrendered page. Step 1108 represents obtaining the data model for thatelement. Note that not all interaction is necessarily related to a datamodel, e.g., a user may interact to expand text that is already presentin the currently retrieved data model, a user may interact to scroll andso on, however it is understood that step 1108 is for when a new datamodel is needed.

It also should be noted that because a higher-level data model (parent)has the identifier information for its lower-level data model or models(children), it is feasible to pre-fetch and cache any lower-level datamodel (and possibly its children, and so on) in anticipation of the needfor the lower-level data model. Thus, instead of waiting for userinteraction, some pre-fetching (and possibly pre-rendering) work may beperformed that reduces any latency issues and thereby increases theperceived speed of the program. Thus, as used herein, “access” and thelike (e.g., “accessed,” “accessing” and so on) with respect to a datamodel may result from retrieval of the data model before any userinteraction, as well as in response to user interaction.

Step 1110 evaluates whether the selected element and any retrieved datamodel is related to search. If not, step 1112 evaluates (e.g., in thenavigation router) whether the selected element is related to a new menulocation by a new data model object of this type. If so, step 1112returns to step 1104 to render the new menu page with its correspondingUI element(s), and so on, until the user selects a non-menu UI elementor takes some other action.

If not a menu location, step 1114 evaluates whether the new page is acontent player location. If so, step 1116 plays the correspondingcontent identified in the data model object, (although as mentionedabove, a more complex content player page may be provided).

If not a search location, menu location or content player location, thanthe non-data driven navigation interaction (in this simplified example)is handled at step 1122. Examples of non-data driven navigationinteraction may include home and back button navigation, expanding orcollapsing a data item, scrolling, and so forth.

Search is represented at steps 1118 and 1120. If there is more than onetype of search page, then a different data model (step 1108) is used toguide the rendering of the page in accordance with that model.Otherwise, the search page is rendered as specified by a single datamodel.

Any search results are presented to the user via step 1120. For example,this may be a special list menu of items that match the search, whichmay wait for an “Enter” command, or alternatively be dynamically updatedas the user enters new characters or categories. Other actions takenwhile searching may be to select an item that is found via the searchpage, which may include accessing the data model for the item selected.It is also feasible that the search results in another menu, in whichstep 1120 handles the search results by obtaining a data model for thatmenu and returning to step 1104 (as represented by the dashed arrow fromstep 1120 to step 1104).

As can be seen, locations, which represent navigable ‘pages’ based ondata are rendered in View Hosts, which comprise the UI thatinteractively displays that data to the user. The platform navigationsystem, described herein and generally represented in FIGS. 1 and 2, maybe encapsulated in a navigator object and a NavigationRouter object, andincludes a number of features that are significantly different from aconventional navigation system, including data-driven navigation.

With data-driven navigation, the navigator traverses to and fromlocations; the NavigationRouter works with the navigator, e.g., bypassing the data model associated with a user action to theNavigationRouter. The NavigationRouter is configured to map data modelsto locations, whereby as services or locations are added or removed, andUI on existing pages needs to be updated to account for the change,there is a consolidated way of processing navigation actions.

Turning to another aspect, in a conventional navigation system, a givenlocation typically allows for only two actions, like a stack, namelytraversal forwards through a link, which creates a new entry in thenavigation history, or traversal backwards to a previous location, whichremoves the current location from the history. In contrast, thenavigator allows for lateral navigation as well, which both adds a newentry to the history and removes the current link from the history.

By way of example, consider that as represented by the hierarchy 1200navigated in FIG. 12A, a user may navigate from “Home” to a “FeaturedMovies” menu or from “Home” to a “Suggested Movies” menu (backwardsnavigation is also allowed). By placing a UI element for a category atthe same hierarchical level, lateral (peer) navigation is alsoavailable. In this example, a UI element for “Featured Movies” ispresent in the “Suggested Movies” menu, whereby lateral navigation from“Featured Movies” to “Suggested Movies” is possible. Note that in thisexample, a UI element for “Suggested Movies” is similarly present in the“Featured Movies” menu, whereby lateral navigation is available in bothdirections, as indicated by the arrow. In this example, items below eachmenu are movies, each bound to a content (movie) player location.

Instead of maintaining a full stack history, the navigation systemdescribed herein is able to navigate hierarchically. For example, if auser navigates laterally between the “Suggested Movies” menu and the“Featured Movies” menu any number of times, the “Back” button stillmoves the user up a hierarchical level, that is, to the “Home” menu.Perhaps more beneficial is that a user clicking through the variousitems hierarchically underneath the “Featured Movies” or “SuggestedMovies” menu, e.g., twenty items, does not have to back out through alltwenty items to get back to the “Featured Movies” menu, but rathersimply selects the Back button once.

This generally may be performed by having the navigation system maintainonly one item per lateral level in a hierarchically-leveled stack. Anexample stack 1220 is shown in FIG. 12B, where a back button selected atany level moves the user up the stack (until “Home” is reached). Notethat in a more complex hierarchy there may be many additional levels,such as for sub-menus of menus and sub-menus of those sub-menus, and soon, however FIG. 12B represents a stack the hierarchy of FIG. 12A. Inany event, only one item may be maintained per hierarchical level toprovide for a hierarchical-based stack traversal. It is feasible forsome limited number of items to be maintained per level, such as twoitems per level instead of one item, for example.

Thus, in a common stack-style navigation system, navigating through lotsof related content can build up a relatively large stack of history; forcontent that is hierarchical, navigating through each element in a groupcan make it difficult to return to the location for the group itself,because the user has to back out again through each item visited.Instead, via a hierarchical stack navigation system, allowing lateralnavigation but maintaining only one item in the same level of ahierarchy, as in FIGS. 12A and 12B, solves this problem, because onlythe current item in that level exists in the history, and traversingback returns the user to the location for the group above instead.

Another common feature of a conventional navigation system is a link to‘Home’ or to a similar higher-level location. This typically clears outthe existing history and starts the user over, as though the user hadjust started a session with the application from scratch.

In contrast, the navigator described allows for a more flexible concept,referred to as an ‘anchor’ herein, as generally represented in FIG. 13A.To this end, history from the top-level to the anchor point may bepreserved, but history beyond the anchor point may be discarded. Thisoperation can be configured to occur either when navigating to or froman anchor.

In the example of FIG. 13A, the navigation stack may be “Home” (level0)->“Popular” (level 1)->Search (level 2)->Result 1 (level 3; in thisexample, although as is understood, it may be whatever result item wasthe last search result). Thus, the user can go “back” to the Search(level 2) anchor but not lose the intermediate “Popular” page in thenavigation stack.

Discarding the history below after navigation from an anchor is usefulbecause it gives the user a second chance to avoid the history beingdeleted if the user mistakenly traverses to a new location. For example,if a user has a great deal of history, and accidentally navigates to ahigher-level location that is marked as an anchor, the user can traverseto the previous location without losing that history. Only if the usernavigates forward again from that top-level location is the historycleared, which confirms an intent to abandon the previous history.

Moreover, anchor locations do not have to be ‘top-level’ locations inthe application. In the example 1300 of FIG. 13A, the application has a‘Home’ location and a ‘Search’ (level 1) location that is accessiblefrom ‘Home’. However, ‘Search’ is also somewhat like a top-levellocation, because the user may navigate to a number of pages fromSearch, then link directly back to Search and navigate elsewhere. Theseredundant Search queries showing up in the history again is likely notwhat the user wants, so clearing the history is desirable, but the useralso likely wants to be able to navigate back from Search to Home.Marking Search as an anchor yields this behavior, because the portion ofthe history from the root (Home) to the anchor (Search) can be preservedwhen the user traverses back to the anchor.

Another capability of the navigation system (e.g., the NavigationRouter) is history generation, which refers to the ability toautomatically generate history for the user based on the data type.Certain kinds of data, such as a video, can be launched withouttraversing many pages. History generation may be used to ensure that auser has certain kinds of locations in the user's history (e.g., thedetail location for the movie or episode being played). This alsoenables a user to jump directly into a location anywhere in theapplication via a deep-link, and for the application to create anappropriate set of history for that user that simulates how they mayhave navigated there interactively.

For example, as represented in FIG. 13B, if a user deep-links directlyto a video such as from the home page, the initial stack 1330 is simplyfrom “Home”->“MovieID”->Movie Player.” History may be generated by anavigation router with history generation capabilities (block 1332) toprovide a modified stack 1334 containing“Home”->“Genres”->“Comedy”->“MovieID”->Movie Player.” Navigation backtowards Home is thus via a different navigation path than originallytaken by the user.

The historically generated information is obtainable via the data model,e.g., it is determinable from the data model that the genre of the movieassociated with this ID is comedy. However, this is only one example;the generated history may instead have been “Popular” between home andthe movie. Determination of what history to generate may be random, butalternatively may be based upon concepts such as past user behavior,statistics of other users and so forth.

As can be seen, the technology described herein passes in a datastructure to a navigation system, which looks at data in the datastructure to navigate. This data-driven navigation has numerous benefitsand advantages, including but not limited to changing program actionsbased upon changes to data and/or a data hierarchy (rather than changingprogram code), and providing for straightforward peer navigation andhierarchical navigation.

One or more aspects are directed towards rendering a representation of anavigation location, including providing a set of one or moreinteractive user interface elements that are each bound to a data model.A selected user interface element that is bound to an associated datamodel is selected, and the associated data model accessing. Data in theassociated data model is used to determine a next navigation location.

The associated data model may include data that indicates that the nextnavigation location is a menu location having another set of one or moreinteractive user interface elements that are each bound to a data model.Navigation to the menu location is described, including rendering arepresentation of the menu location that includes the other set of theone or more interactive user interface elements.

A next navigation location may be a content player location,corresponding to rendering a representation of the content playerlocation. The content player location may play content identified in theassociated data model.

The next navigation location may be a search location. If so, arepresentation of the search location is rendered.

The associated data model may be changed so that a subsequent navigationis to a different location. The associated data model may include datathat indicates that the next navigation location is a menu locationhaving another set of one or more interactive user interface elementsthat are each bound to a data model; the associated data model may bechanged to have a different set of one or more interactive userinterface elements.

The associated data model may be part of a hierarchy of data models,which may be changed by changing the data of at least one data model.

One or more aspects are directed towards data models arranged in ahierarchy, in which the hierarchy is based upon information in eachhigher-level data model that binds that higher-level data model to a setcomprising one or more lower-level data models. A navigation system isconfigured to use data in a higher-level data model to access alower-level data model of the higher level model's set. The navigationsystem includes a navigation router that uses data in the lowerlower-level data model to determine a navigation location to which tonavigate to provide a user interface that corresponds to the navigationlocation and is based upon the lower-level data model.

The navigation router may map location type information in thelower-level data model to a location. The navigation location mayinclude one or more user interface objects rendered in a view object.

The higher-level data model may correspond to a higher-level menunavigation location having an interactive user interface element boundto the lower-level data model, and the navigation system may navigate tothe navigation location identified in the selected lower-level datamodel based upon interaction with the interactive user interfaceelement. The interaction may cause navigation among hierarchical levelsof navigation locations that correspond to the data model hierarchy, andthe navigation system may maintain a navigation stack containing onlyone location for each hierarchical level.

The navigation system may provide an anchor location above whichnavigation history is maintained and below which navigation history isdiscarded. The navigation history may be discarded if user intentindicates that the navigation history is to be discarded.

The navigation system automatically may generate at least part of anavigation history to simulate a navigation stack. For example if deeplinking to a data element, a path, including a location for eachhierarchical level between the element and the location, may besimulated.

One or more aspects are directed towards presenting a menu to a user,the menu containing at least one interactive navigation element bound toa data model, and detecting selection of an interactive navigationelement. A set of data models is accessed to locate a data modelassociated with the interactive navigation element, and the data modelused to determine a navigation location. Navigating to the navigationlocation is further described.

Navigating to the navigation location may comprise rendering a pagecontaining visible information that is based at least in part upon thedata model, and allowing user interaction with the page. A reference tothe navigation location may be maintained in a navigation stack,including replacing any reference in the navigation stack thatreferences a location in a same hierarchical level to which the pagecorresponds. Navigating to the navigation location may comprise invokinga content player that plays audiovisual content associated with thenavigation location.

Example Computing Device

The techniques described herein can be applied to any device or set ofdevices (machines) capable of running programs and processes. It can beunderstood, therefore, that personal computers, laptops, handheld,portable and other computing devices and computing objects of all kindsincluding cell phones, tablet/slate computers, gaming/entertainmentconsoles and the like are contemplated for use in connection withvarious implementations including those exemplified herein. Accordingly,the general purpose computing mechanism described below in FIG. 14 isbut one example of a computing device.

Implementations can partly be implemented via an operating system, foruse by a developer of services for a device or object, and/or includedwithin application software that operates to perform one or morefunctional aspects of the various implementations described herein.Software may be described in the general context of computer executableinstructions, such as program modules, being executed by one or morecomputers, such as client workstations, servers or other devices. Thoseskilled in the art will appreciate that computer systems have a varietyof configurations and protocols that can be used to communicate data,and thus, no particular configuration or protocol is consideredlimiting.

FIG. 14 thus illustrates an example of a suitable computing systemenvironment 1400 in which one or aspects of the implementationsdescribed herein can be implemented, although as made clear above, thecomputing system environment 1400 is only one example of a suitablecomputing environment and is not intended to suggest any limitation asto scope of use or functionality. In addition, the computing systemenvironment 1400 is not intended to be interpreted as having anydependency relating to any one or combination of components illustratedin the example computing system environment 1400.

With reference to FIG. 14, an example device for implementing one ormore implementations includes a general purpose computing device in theform of a computer 1410. Components of computer 1410 may include, butare not limited to, a processing unit 1420, a system memory 1430, and asystem bus 1422 that couples various system components including thesystem memory to the processing unit 1420.

Computer 1410 typically includes a variety of machine (e.g., computer)readable media and can be any available media that can be accessed by amachine such as the computer 1410. The system memory 1430 may includecomputer storage media in the form of volatile and/or nonvolatile memorysuch as read only memory (ROM) and/or random access memory (RAM), andhard drive media, optical storage media, flash media, and so forth; asused herein, machine readable/computer readable storage media storesdata that does not include transitory signals, (although other types ofmachine readable/computer readable media that is not storage media may).By way of example, and not limitation, system memory 1430 may alsoinclude an operating system, application programs, other programmodules, and program data.

A user can enter commands and information into the computer 1410 throughone or more input devices 1440. A monitor or other type of displaydevice is also connected to the system bus 1422 via an interface, suchas output interface 1450. In addition to a monitor, computers can alsoinclude other peripheral output devices such as speakers and a printer,which may be connected through output interface 1450.

The computer 1410 may operate in a networked or distributed environmentusing logical connections to one or more other remote computers, such asremote computer 1470. The remote computer 1470 may be a personalcomputer, a server, a router, a network PC, a peer device or othercommon network node, or any other remote media consumption ortransmission device, and may include any or all of the elementsdescribed above relative to the computer 1410. The logical connectionsdepicted in FIG. 14 include a network 1472, such as a local area network(LAN) or a wide area network (WAN), but may also include othernetworks/buses. Such networking environments are commonplace in homes,offices, enterprise-wide computer networks, intranets and the Internet.

As mentioned above, while example implementations have been described inconnection with various computing devices and network architectures, theunderlying concepts may be applied to any network system and anycomputing device or system in which it is desirable to implement suchtechnology.

Also, there are multiple ways to implement the same or similarfunctionality, e.g., an appropriate API, tool kit, driver code,operating system, control, standalone or downloadable software object,etc., which enables applications and services to take advantage of thetechniques provided herein. Thus, implementations herein arecontemplated from the standpoint of an API (or other software object),as well as from a software or hardware object that implements one ormore implementations as described herein. Thus, various implementationsdescribed herein can have aspects that are wholly in hardware, partly inhardware and partly in software, as well as wholly in software.

The word “example” is used herein to mean serving as an example,instance, or illustration. For the avoidance of doubt, the subjectmatter disclosed herein is not limited by such examples. In addition,any aspect or design described herein as “example” is not necessarily tobe construed as preferred or advantageous over other aspects or designs,nor is it meant to preclude equivalent example structures and techniquesknown to those of ordinary skill in the art. Furthermore, to the extentthat the terms “includes,” “has,” “contains,” and other similar wordsare used, for the avoidance of doubt, such terms are intended to beinclusive in a manner similar to the term “comprising” as an opentransition word without precluding any additional or other elements whenemployed in a claim.

As mentioned, the various techniques described herein may be implementedin connection with hardware or software or, where appropriate, with acombination of both. As used herein, the terms “component,” “module,”“system” and the like are likewise intended to refer to acomputer-related entity, either hardware, a combination of hardware andsoftware, software, or software in execution. For example, a componentmay be, but is not limited to being, a process running on a processor, aprocessor, an object, an executable, a thread of execution, a program,and/or a computer. By way of illustration, both an application runningon a computer and the computer can be a component. One or morecomponents may reside within a process and/or thread of execution and acomponent may be localized on one computer and/or distributed betweentwo or more computers.

The aforementioned systems have been described with respect tointeraction between several components. It can be appreciated that suchsystems and components can include those components or specifiedsub-components, some of the specified components or sub-components,and/or additional components, and according to various permutations andcombinations of the foregoing. Sub-components can also be implemented ascomponents communicatively coupled to other components rather thanincluded within parent components (hierarchical). Additionally, it canbe noted that one or more components may be combined into a singlecomponent providing aggregate functionality or divided into severalseparate sub-components, and that any one or more middle layers, such asa management layer, may be provided to communicatively couple to suchsub-components in order to provide integrated functionality. Anycomponents described herein may also interact with one or more othercomponents not specifically described herein but generally known bythose of skill in the art.

In view of the example systems described herein, methodologies that maybe implemented in accordance with the described subject matter can alsobe appreciated with reference to the flowcharts/flow diagrams of thevarious figures. While for purposes of simplicity of explanation, themethodologies are shown and described as a series of blocks, it is to beunderstood and appreciated that the various implementations are notlimited by the order of the blocks, as some blocks may occur indifferent orders and/or concurrently with other blocks from what isdepicted and described herein. Where non-sequential, or branched, flowis illustrated via flowcharts/flow diagrams, it can be appreciated thatvarious other branches, flow paths, and orders of the blocks, may beimplemented which achieve the same or a similar result. Moreover, someillustrated blocks are optional in implementing the methodologiesdescribed herein.

CONCLUSION

While the invention is susceptible to various modifications andalternative constructions, certain illustrated implementations thereofare shown in the drawings and have been described above in detail. Itshould be understood, however, that there is no intention to limit theinvention to the specific forms disclosed, but on the contrary, theintention is to cover all modifications, alternative constructions, andequivalents falling within the spirit and scope of the invention.

In addition to the various implementations described herein, it is to beunderstood that other similar implementations can be used ormodifications and additions can be made to the describedimplementation(s) for performing the same or equivalent function of thecorresponding implementation(s) without deviating therefrom. Stillfurther, multiple processing chips or multiple devices can share theperformance of one or more functions described herein, and similarly,storage can be effected across a plurality of devices. Accordingly, theinvention is not to be limited to any single implementation, but ratheris to be construed in breadth, spirit and scope in accordance with theappended claims.

What is claimed is:
 1. A method performed at least in part on at leastone machine, comprising, rendering a representation of a navigationlocation, including providing a set of one or more interactive userinterface elements that are each bound to a data model, detectingselection of a selected user interface element that is bound to anassociated data model, accessing the associated data model, and usingdata in the associated data model to determine a next navigationlocation.
 2. The method of claim 1 wherein the associated data modelincludes data that indicates that the next navigation location comprisesa menu location having another set of one or more interactive userinterface elements that are each bound to a data model, and furthercomprising, navigating to the menu location, including rendering arepresentation of the menu location that includes the other set of theone or more interactive user interface elements.
 3. The method of claim1 wherein the next navigation location comprises a content playerlocation and further comprising, rendering a representation of thecontent player location.
 4. The method of claim 3 wherein rendering therepresentation of the content player location plays content identifiedin the associated data model.
 5. The method of claim 1 wherein the nextnavigation location comprises a search location and further comprising,rendering a representation of the search location.
 6. The method ofclaim 1 further comprising, changing the associated data model to changea subsequent navigation to a different location.
 7. The method of claim1 wherein the associated data model includes data that indicates thatthe next navigation location comprises a menu location having anotherset of one or more interactive user interface elements that are eachbound to a data model, and further comprising, changing the associateddata model to have a different set of one or more interactive userinterface elements upon a subsequent navigation to the next menulocation.
 8. The method of claim 1 further comprising, wherein theassociated data model is part of a hierarchy of data models, and furthercomprising, changing the hierarchy of data models by changing the dataof at least one data model.
 9. A system, comprising: a plurality of datamodels arranged in a hierarchy, in which the hierarchy is based uponinformation in each higher-level data model that binds that higher-leveldata model to a set comprising one or more lower-level data models, anda navigation system configured to use data in a higher-level data modelto access a lower-level data model of the higher level model's set, thenavigation system including a navigation router that uses data in thelower lower-level data model to determine a navigation location to whichto navigate to provide a user interface that corresponds to thenavigation location and is based upon the lower-level data model. 10.The system of claim 9 wherein the navigation router maps location typeinformation in the lower-level data model to a location.
 11. The systemof claim 9 wherein the navigation location comprises one or more userinterface objects rendered in a view object.
 12. The system of claim 9wherein the higher-level data model corresponds to a higher-level menunavigation location having an interactive user interface element boundto the lower-level data model, and wherein the navigation systemnavigates to the navigation location identified in the selectedlower-level data model based upon interaction with the interactive userinterface element.
 13. The system of claim 12 wherein the interactioncauses navigation among hierarchical levels of navigation locations thatcorrespond to the data model hierarchy, including navigation betweennavigation locations within a same hierarchical level, and wherein thenavigation system maintains a navigation stack containing only onelocation for each hierarchical level.
 14. The system of claim 9 whereinthe navigation system provides an anchor location above which navigationhistory is maintained and below which navigation history is discarded.15. The system of claim 9 wherein the navigation system provides ananchor location above which navigation history is maintained and belowwhich navigation history is discarded if user intent indicates that thenavigation history is to be discarded.
 16. The system of claim 9 whereinthe navigation system automatically generates at least part of anavigation history to simulate a navigation stack.
 17. One or moremachine-readable media having computer-executable instructions, whichwhen executed perform steps, comprising: presenting a menu to a user,the menu containing at least one interactive navigation element bound toa data model; detecting selection of an interactive navigation element;accessing a set of data models to locate a data model associated withthe interactive navigation element; using the data model to determine anavigation location; and navigating to the navigation location.
 18. Theone or more machine-readable media of claim 17 wherein navigating to thenavigation location comprises rendering a page containing visibleinformation that is based at least in part upon the data model, andallowing user interaction with the page.
 19. The one or moremachine-readable media of claim 18 having further computer-executableinstructions comprising, maintaining a reference to the navigationlocation in a navigation stack, including replacing any reference in thenavigation stack that references a location in a same hierarchical levelto which the page corresponds.
 20. The one or more machine-readablemedia of claim 17 wherein navigating to the navigation locationcomprises invoking a content player that plays audiovisual contentassociated with the navigation location.